Modern electronic devices such as computers, tablets, mobile phones, wearable devices and the like have become a common part of modern life. Many users of electronic devices routinely utilize various types of software applications for business and personal activities. Examples of software applications can include word processors, spreadsheet applications, e-mail clients, notetaking software, presentation applications, games, computational software, and others. These software applications can also be used to perform calculations, produce charts, organize data, receive and send e-mails, communicate in real-time with others, and the like. The software applications can range from simple software to very complex software.
The development of complex software is often performed by teams of software developers with designated roles. In many cases, code review is an iterative process where each line of code within the software is reviewed by one or more code reviewers apart from the author to ensure that the code will perform as expected. The code reviewers often comment on the current version of the code and request one or more changes. The comments on the current version of the code are communicated to one of the team members who makes additional changes before submitting the code for additional review.
In many cases, a diffing tool can be used to compare the changes that the developer has made to one or more files of the code. Typically, a code review compares the developer's version of the file (i.e., a iteration1) against the version of the file that is in the central repository (e.g., baseFile1). By identifying the changes to the code from the previous version, the next review can more easily confirm that the desired changes were made without having to reevaluate all of the code. However, with complex software products it is not uncommon for multiple developers to be working on the code at the same time. As such, just creating a straight diff of versions of the file may identify changes made by other developers. This can cause extra work for a reviewer that is not responsible for other portions of the code in trying to understand why a portion of code changed.
Overall, the examples herein of some prior or related systems and their associated limitations are intended to be illustrative and not exclusive. Upon reading the following, other limitations of existing or prior systems will become apparent to those of skill in the art.